Section: New Results

Liability issues in software engineering

Software contracts usually include strong liability limitations or even exemptions of the providers for damages caused by their products. This situation does not favour the development of high quality software because software editors do not have sufficient economic incentives to apply stringent development and verification methods. Indeed, experience shows that products tend to be of higher quality and more secure when the actors in position to influence their development are also the actors bearing the liability for their defects. The usual argument to justify this lack of liability is the fact that software products are too complex and versatile objects whose expected features (and potential defects) cannot be characterised precisely, and which thus cannot be treated as traditional (tangible) goods. Taking up this challenge is one of our objectives [12] : we study liability issues both from the legal and the technical points of view with the aim to put forward a formal framework to (1) define liability in a precise and unambiguous way and (2) establish such liability in case of incident.

Obviously, specifying all liabilities in a formal framework is neither possible nor desirable. Usually, the parties wish to express as precisely as possible certain aspects which are of prime importance for them and prefer to state other aspects less precisely (either because it is impossible to foresee at contracting time all the events that may occur or because they do not want to be bound by too precise commitments). Taking this requirement into account, we provide a set of tools and methods to be used on a need basis in the contract drafting process (as opposed to a monolithic, “all or nothing” approach). Our model is based on execution traces which are abstractions of the log files of the system. In a nutshell, liability is specified as a function taking as parameters a claim and an execution trace and returning a set of “responsible” actors. This set of actors (ideally a singleton) depends on the claim and the errors occuring in the trace. Both errors and claims are expressed as trace properties. The liability function can be made as precise or detailed as necessary by choosing the claims and errors relevant for a given situation [5] .

In order to provide a more generic way to define liabilities, we have also introduced a concept of “logical causality” [11] . Causality has been studied for a long time in computer science, but with quite different perspectives and goals. In the distributed systems community, causality is seen essentially as a temporal property. We have defined several variants of logical causality allowing us to express the fact that an event $e_2$ (e.g. a failure) would not have occurred if another event $e_1$ had not occurred (“necessary causality”) or the fact that $e_2$ could not have been avoided as soon as $e_1$ had occurred (“sufficient causality”). We have applied these technical definitions of causality to real case studies and related them to the legal views of causality.

As far as legal issues are concerned, we have studied the legal validity of the technical solutions proposed in the project both in terms of legal evidence and allocation of liabilities [6] . Contract templates have been defined in collaboration with lawyers to allow the parties to effectively integrate our results in a legal contract [6] .